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PREFACE 


This  report  is  the  result  of  work  performed  under  Contract  No. 
DACA39-78-M-OO53,  dated  25  January  1978,  between  the  U,  S,  Arny  Engineer 
Waterways  Experiment  Station  (WES),  Vicksburg,  Miss.,  and  the  author, 
Richard  F.  Puk,  Graphics  Consultant.  The  work  concerned  designing 
host-computer  implementation  guidelines  for  the  three-dimensional  version 
(2.0)  of  the  Graphics  Compatibility  System  (GCS).  The  task  was  directed 
by  the  Automatic  Data  Processing  (ADP)  Center,  WES,  as  part  of  Com- 
puter Technology-Engineering  Software,  Project  No.  ^A762725AT11 , 
sponsored  by  the  Office,  Chief  of  Engineers,  U.  S.  Army. 

Mr,  James  M.  Jones  II,  R&D  Software  Group,  ADP  Center,  WES,  monitored 
the  contract  under  the  general  supervision  of  Dr.  N.  Radhakrishnan,  Special 
Technical  Assistant  to  the  Chief  of  the  ADP  Center,  and  Mr.  D.  L.  Neumann, 
Chief  of  the  ADP  Center. 

Director  of  WES  during  the  period  of  the  contract  was  COL  J.  L. 
Cannon,  CE.  Technical  Director  was  Mr.  F.  R.  Brown. 
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I.  Introduction. 


The  following  paragraphs  develop  guidelines  for  Imple- 
menting GCS  on  a host  computer  system.  Included  will  be  the 
definition  of  computer-dependent  Graphics  Status  Area  (GSA) 
Initialization  values,  functional  specifications  for  each 
of  the  3D  GCS  computer-dependent  routines,  a discussion  of 
factors  Involved  In  supporting  3D  GCS  on  a computer  system, 
and  a description  of  a phased  sequence  for  bringing  up  GCS 
on  a new  computer  system. 

II.  Graphics  Status  Area  Initialization. 

In  this  section,  each  of  the  computer-dependent  elements 
of  the  Graphics  Status  Area  will  be  listed  along  with  the 
procedures  required  to  calculate  the  value.  If  appropriate. 

KTERM  GCS  string  terminator  character.  Default  value  Is 
the  Internal  computer  character  set  representation 
of  an  ASCII  backslash  ("\")  character. 

KUCASB  Upper  case  shift  character.  Default  value  Is  the 
Internal  computer  character  set  representation  of 
an  ASCII  less-than  {"<")  character. 

KLCASE  Lower  case  shift  character.  Default  value  Is  the 
Internal  computer  character  set  representation  of 
an  ASCII  greater-than  (">")  character. 

SSUBCH  Subscript  escape  character.  Default  value  Is  the 
Internal  computer  character  set  representation  of 
an  ASCII  underscore  character. 

ESUPCH  Superscript  escape  character.  Default  value  Is  the 
Internal  computer  character  set  representation  of 
an  ASCII  pound  sign  ("#")  character. 

KWRT7L  Standard  alphanumeric  output  file.  Default  value 
Is  the  computer  system  default  alphanumeric  output 
Fortran  file  number. 

KRDFL  Standard  alphanumeric  Input  file.  Default  value  Is 
the  computer  system  default  alphanumeric  Input 
Fortran  file  number. 

KOUTFL  Standard  graphics  output  file.  Default  value  is 

the  computer  system  default  graphics  output  Fortran 
file  number  If  one  exists. 
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•5D  GOS  Computer-dependent  Routines. 

This  section  describes  the  functions  embodied  in  each  of  I 

the  3D  GCS  computer-dependent  routines.  This  discussion 
will  include  interface  specifications  and  functional  speci- 
fications. Since  these  functions  are  computer-dependent, 
the  requirement  to  implement  these  routines  in  ANS  Fortran 
is  relaxed.  However,  use  of  a higher-level  language  for 
implementation  is  recommended  for  ease  of  maintenance.  The 
functions  are  grouped  into  four  categories:  packing.  Job 
control,  character  set  conversion,  and  I/O.  Within  these 
categories,  the  routines  will  be  listed  alphabetically. 
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The  paclrlng  routines  provide  for  oacking  and  unpacking 
arbitrary  length  bit  strings  (GCSBIT,  GCSBTR),  for  packing 
and  unpacking  single  characters  (GCS1CH,  GCS1PK),  and  for 
extracting  the  left-most  n-character  wide  field  from  a 
character  string  (GCSSTD)*  Two  former  computer-dependent 
routines,  GCSPCK  and  GOSOPK,  have  been  rewritten  to  call 
G0S10H  and  GCS1PK  and  are  now  device  and  computer  system 
independent. 


GCSBIT  (NEXT , IVf  IDTH , IWORD , IBITLC , IBUP ) 


NEXT 

WIDTH 

IWOBD 

IBITLC 

IBUF 

Comments: 


I 


Is  a word  containing  the  bits  to  be  packed 
right-justified , zero-fill. 

is  the  number  of  bits  to  be  packed  (1.  e.,  the 
number  of  bits  In  NEXT). 

Is  the  word  In  the  buffer  In  which  packing  will 
occur. 

Is  the  number  of  bits  currently  used  within 
IWORD. 

Is  an  array  In  which  the  bit  string  Is  accumulated. 
The  calling  routine  should  provide  a buffer  one 
word  larger  than  the  actual  buffer  size  since 
GCSBIT  will  leave  overflow  bits  In  this  word. 

This  routine  accumulates  a packed  bit  string  of 
arbitrary  length  within  a buffer  provided  by  the 
calling  program.  This  allows  the  formation  of 
strings  of  bits  In  which  the  storage  of  the  bits 
‘gnores  word  boundaries. 
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GCSBTR  (NEXT , WIDTH , WORD , I3ITLC , IBUP  ) 

NEXT  Is  a word  In  which  the  bits  retrieved  will  be 
placed  right-justified,  zero-fill. 

WIDTH  Is  the  number  of  bits  to  be  retrieved  (1.  e., 
placed  In  NEXT). 

WORD  Is  the  word  In  the  buffer  from  which  bits  are 
ciu'rently  being  retrieved, 

IBITLC  Is  the  number  of  bits  already  retrieved  from 
WORD. 

IBUP  Is  an  array  containing  the  bit  string  from  which  i 

bits  will  be  retrieved.  The  calling  routine  j 

should  provide  a word  of  zero  bits  Immediately 
following  the  I3DP  array. 

Comments;  This  routine  retrieves  string  of  bits  (up  to  one 
word)  from  the  packed  bit  string  provided  by  the 
calling  program  (1.  e,,  the  buffer  IBUP).  Word  i 

boundaries  will  be  Ignored  during  retrieval.  j 
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GCS  t PK(lf , INCHAH , IBUPR ) 


N 

INCHAH 

IBUPR 

Commeats : 


i 


is  the  character  position  within  the  output 
character  string  Into  which  the  KBYTEL-wldth 
character  Is  to  be  packed. 

Is  a word  containing  one  KBYTEL-wldth  character  j 

rlght-Jus tlfled , zero-fill.  ) 

I 

Is  the  output  character  string  word  Into  which  ! 

the  KBYTEL-wldht  character  will  be  Inserted. 

This  routine  Inserts  the  KBYTEL-wldth  character  ^ 

contained  In  INCHAR  Into  the  N^ii  KBYTEL-wldth  i 

character  position  of  the  output  character  string  J 

IBUPR.  Character  positions  are  numbered  left  to 

right.  Note  that  K3YTEL  Is  not  a fixed  quantity  j > 

and  may  vary  during  execution.  i 
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GCS 1 CH ( N , ISTRNG , NUCHAR ) 

N the  character  position  within  the  Input  character 
string  from  which  the  K3YTSL-wldth  character  Is 
to  be  extracted. 

ISTRNG  is  the  input  character  string  (maximum  length  is 
one  word). 

NUCHAR  is  a word  in  which  the  K3fT2L-wldth  character  is 
placed. 

Comments;  This  routine  extracts  the  K3fTZL-wldth  charac- 

ter from  the  input  character  string  word  and  places 
it  in  the  output  word  (N'JCHaH)  right-justified, 
zero-fill.  Note  that  Is  not  a fixed  quantity 

and  may  vary  during  execution. 
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GCSSTD (N , ISTSNG .NUSTRG ) 


N Is  the  number  of  left-most  characters  from  the 
Input  character  string  to  comprise  the  output 
character  string. 

ISTRNG  Is  the  Input  character  string. 

NUSTRG  Is  the  left- justified  output  character  string 
padded  with  zero  bits  If  necessary  to  fill  the 
word. 

Comments:  This  routine  places  the  left-most  N characters 
from  the  Input  character  string  In  the  output 
character  string  word  padding.  If  necessary,  with 
zero  bits.  Both  the  Input  and  output  character 
strings  may' be  of  maximum  length  of  four  characters 
or  one  word  whichever  Is  greater. 
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Job  Oontrol  Routines 

Only  two  Job  control  routines  currently  are  required, 

GCSJOB  and  GCSTBK.  These  routines  are  intended  to  access  ' 

operating  system  facilities  for  services  or  to  obtain 

information. 

\ 
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GCSJOB ( JOBID , ID USER , IRODTE , ICLASS , IDATE , ITIME ) 


JOBID  Is  a word  In  which  the  Job  ID  of  the  run  will  be 
returned . 

IDUSER  is  a word  In  which  the  ID  of  the  person  executing 
the  program  will  be  returned. 

IRODTE  is  the  routing  address  to  which  the  output  should 
be  sent. 

ICLASS  is  the  Job  security  classification. 

IDATE  is  the  date  of  the  run. 

ITIMS  is  the  time  of  the  call  to  GCSJOB. 

Comment:  The  GCS  terminator  character  la  appended  to  the 

end  of  each  field  of  information  being  returned  to 
the  calling  program.  The  calling  program  has  the 
responsibility  of  insuring  that  the  current  termi- 
nator is  the  default  terminator. 

A maximum  of  twelve  characters  including  the  GCS 
terminator  character  are  allowed  to  be  returned 
for  each  field.  The  only  exception  is  that  the 
security  classification  may  be  up  to  eight  words 
long. 

If  a parameter  is  not  defined  on  a particular 
operating  system,  a valid  GCS  text  string  consist- 
ing of  only  the  default  GCS  text  string  terminator 
must  be  provided. 


******  This  routine  is  still  under  development,  ******  > 
******  The  description  above  is  subject  to  ******  ^ r 
******  change.  Providing  this  routine  is  opt-  ******  i 
******  lonal  until  development  is  completed,  ******  t 
******************************************************** 


! 'it 


GCSTBK(IERROR) 


ZERBOR  contains  the  GCS  error  number. 

Comments:  This  routine  invokes  the  computer  system  error 
traceback  routine.  It  is  implemented  so  that 
tracebacks  can  occur  when  GCS  errors  have  been 
identified.  It  is  important  that  the  traceback 
not  abort  execution  of  the  program.  If  no 
traceback  function  exists  or  the  traceback 
aborts  execution  of  the  program,  this  routine 
should  be  null. 


Character  Set  Conversion  Routines 

These  routines  provide  for  converting  between  the  GCS 
internal  character  set  ASCII  and  the  host  computer  internal 
character  set.  Note  that  even  if  the  host  computer  character 
I set  can  support  both  upper  and  lower  case  characters,  the 

mechanism  must  still  be  provided  to  support  the  GCS  case 
shifting  function.  This  may  require  that  duplicate  conver- 
sion tables  be  Included  whose  only  difference  is  that  all 
upper  case  characters  be  mapped  to  lower  case  when  lower 
case  has  been  specified.  If  the  host  computer  character  set 
does  not  support  the  entire  ASCII  special  character  graphics, 
then  some  special  characters  may  also  differ  between  upper 
and  lower  cases.  If  this  occurs,  however,  the  special  charac- 
ters (,  ),  +,  -,  =,  *,  /,  <,  >,  and  \ must  be  supported  in 
both  cases.  Only  the  printable  characters  need  be  converted; 
control  characters  and  character  Indecies  with  nc  graphic 
symbol  associated  with  them  need  not  be  handled  unless  desired. 
It  should  be  emphasized  that  every  attempt  should  be  made  to 
accommodate  the  standard  mapping  between  ASCII  and  the  host- 
computer  character  set  defined  by  the  host-computer  manufac- 
turer for  the  operating  system  being  utilized. 
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GCSCVTdN.lOUT) 


IN  is  the  charcter  to  be  converted  in  host-computer 
Internal  character  set  right-justified,  zero-fill. 

lOUT  is  a word  in  which  the  character  will  be  placed 
after  being  converted  to  ASCII  right-justified , 
zero-fill. 

Comments:  This  routine  converts  from  host-computer  internal 

character  set  to  ASCII.  The  case-shifting  constant 
will  have  been  added  to  the  host-computer  character 
before  this  routine  is  called.  Therefore,  the 
case  shifting  should  be  recognized  by  the  magni- 
tude of  the  character  bit  value. 


GCSRVTdN.IOUT) 


IN  is  the  character  to  be  converted  in  ASCII 
right-justified,  zero-fill. 

lOUT  is  a word  in  which  the  character  will  be  placed 
after  conversion  to  host-computer  internal 
• character  set. 


Comments: 


This  routine  converts  from  ASCII  to  host-computer 
internal  character  set.  Since  ASCII  supports 
both  upper  and  lower  case,  it  may  be  necessary 
to  map  lower  case  characters  into  upper  case 
characters  if  the  host-computer  character  set 
supports  only  upper  case. 
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(}CS0?S(Z7ILCD) 


Z7ILCD  Is  the  Fortran  file  number  of  the  sequential 
file  to  be  opened. 

Oomments:  This  routine  opens  a file  for  sequential  access, 


' i 


i 


Ri 


Three  classes  of  I/O  routines  are  included  in  this 
category:  sequential  file  I/O,  random  file  I/O,  and 
telecommunications  Interface  routines. 

The  sequential  file  I/O  routines  OCSOfS,  OCSR?S,  GCSWFS, 
and  OCSCFS  are  required  for  use  by  devices  which  place  plot 
output  on  sequential  files.  Use  of  these  routines  Is 
required  since  Fortran  I/O  may  place  undesirable  control 
Information  on  a file  when  using  unformatted  I/O  (Formatted 
I/O  cannot  be  used  since  It  is  llne-orlented  with  line 
length  restrictions  on  some  computers). 

The  random  file  I/O  routines  GCSOFR,  GCSRFR,  GCSVTFR,  and 
GCSCFR  are  required  for  supporting  GCS  segmentation  and 
structure  facilities.  These  routines  are  required  since 
ANS  Fortran  does  not  have  random  file  I/O  capability. 

The  telecommunication  routines  TINFUT  and  TOUTFT  are 
required  for  communication  between  GCS  device-dependent 
routines  and  devices  connected  to  the  host-computer  via 
telecommunications  lines.  These  are  required  since  the 
Interface  may  connect  directly  to  the  operating  system 
telecommunications  service  routines. 
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GCSRPR ( IPILCD , INDEX , IRECNR , IRECLN , IRECRD ) 


IPILCD  Is  the  Fortran  file  number  of  the  random  file. 

INDEX  la  an  array  In  which  the  random  file  Index  may 

be  maintained. 

IRECNR  Is  the  record  number  of  the  record  to  be  retrieved. 

IRECLN  Is  the  length  of  the  record  to  be  retrieved. 

IRECRD  Is  an  array  Into  which  the  record  will  be  read. 

Comments:  This  routine  performs  a random  (direct)  read  of 
the  desired  record  from  the  specified  file.  If 
the  record  Is  larger  than  the  buffer  array 
IRECRD,  only  the  first  IRECLN  words  will  be  placed 
In  the  buffer  area.  If  the  record  Is  smaller  than 
the  buffer  area,  the  remaining  words  of  the  buffer 
will  be  unchanged.  If  the  record  does  not  yet 
exist,  the  buffer  array  will  be  zero-filled. 


GCSRPS { IPILOD , ILBNG , IBUPPR , 1ST AT ) 


IPILCB  is  a Fortran  file  number. 

ILMG  specifies  the  length  of  the  input  buffer. 

IBUPPR  is  an  array  of  site  ILBNG  words  into  which 
the  data  will  be  read. 

ISTAT  is  a status  indicator.  Valid  values  are; 

0 = Bnd  of  file 

>0  = Actual  number  of  words  read 
<0  = Brror  ocoured  during  the  read  operation. 
Absolute  value  is  actual  number  of  words 
read. 

Comments;  This  routine  reads  the  next  physical  record  from 
the  file  into  the  buffer.  If  the  number  of  words 
read  is  less  than  the  buffer  size,  unused  buffer 
locations  will  not  be  modified.  If  the  number  of 
words  read  is  greater  that  the  buffer  size,  only 
the  first  ILBNG  words  of  the  record  will  be  placed 
in  the  buffer.  Excess  words  are  discarded.  Note 
that  in  all  oases,  the  number  of  words  read  will 
be  indicated  in  ISTAT.  If  an  end-of-flle  is 
encountered,  ISTAT  is  set  to  zero. 


f 

I 
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GCSOPR ( IPILOD , INDEX , INDXSZ  ) 

IFILCD  Is  the  Fortran  file  number  for  the  random  file.  | 

INDEX  Is  an  array  In  which  the  index  for  the  random 

file  can  be  maintained  if  not  maintained  by  i 

the  operating  system. 


INDXSZ  is  the  number  of  words  in  the  INDEX  array. 

Comments;  This  routine  opens  a file  for  random  access  and 
Initializes  the  index  for  the  file  If  necessary. 
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GCSVfPS  ( IPILCD  .LBNGTH , IBUPPR , ISTAT  ) 

IPILCD  Is  a Portran  file  number. 

ILBNG  specifies  the  number  of  words  of  data  to  be 
written, 

IBUPPR  Is  an  arraj  containing  the  ILSNG  words  of 
data  to  be  written. 

ISTAT  la  a status  Indicator.  Valid  values  are; 

0 = No  error  during  processing.  j 

1 = Error  during  processing.  j 

Comments:  This  routine  writes  the  ILENG  words  of  data  In  • 

the  buffer  to  the  file.  No  other  Information  I 

may  be  placed  on  the  file.  This  means  that  It 

may  not  be  possllbe  to  use  unformatted  Portran  j 

I/O  since  control  Information  Is  frequently  ; 

written  to  the  file  along  with  the  data.  Also, 

It  may  not  be  possible  to  tuse  formatted  Portran  i 

l/O  since  the  number  of  characters  which  can  be 

written  Is  often  limited  to  one  line  and  end-  ' 

of-llne  symbols  may  be  Inserted  within  the  data 

stream.  Since  files  written  using  GCSWPS  are 

often  read  by  tape  drives  attached  to  other  than 

the  host-computer,  It  Is  Important  that  the 

Information  written  to  the  file  contain  no 

computer-system  dependent  control  Information,  • 


i 
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GCSCPS(IPILCD,IEOP) 


IPILCD 

lEOP 

Comments : 


I 


Is  the  Fortran  file  number  of  the  sequential 
file  to  be  closed. 

Is  an  end-of-flle  request  flag.  If  set  to  one, 
an  end-of-flle  mark  Is  written  on  the  end  of 
the  file.  All  other  values  Inhibit  writing  of 
an  end-of-flle. 

This  routine  closes  the  file  specified  In  IPILCD 
If  required  bj  the  computer  system.  An  end-of- 
flle  marie  must  be  written  If  ISO?  has  value  l . 
The  close  operation  takes  place  with  no  rewind. 
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GCSWFR ( IPILCD , INDEX , IHECNR , IRECLN , IRECRD  ) 

IPILCD  Is  the  Fortran  file  nuaber  of  the  random  file  j 

to  be  written  upon. 

i 

INDEX  Is  an  array  which  may  be  used  to  maintain  the 

index  for  the  random  file.  | 

IRSCNR  Is  the  number  of  the  record  to  be  written. 

IRECLN  Indicates  the  number  of  words  In  the  record  to  ' 

be  written. 

IRECRD  Is  an  array  of  IRECLN  words  containing  the  data 
to  be  written. 

I 

Comments*  This  routine  writes  or  rewrites  the  record  j 

Indicated.  If  the  record  did  not  exist  before,  I 

the  record  will  be  written.  If  the  record  already  I 

exists  and  Is  being  modified,  the  record  should  j 

be  rewritten  In  dace. 

- i 
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50SCPR(IPILCD) 

Il’ILCD  Is  a Fortran  file  number. 

Comments;  This  routine  closes  the  random  file  Indicated 
by  IFILCD.  Clsolng  a random  file  may  require 
Invocation  of  an  operating  system  support 
routine  to  vrrlte  the  Index  on  to  the  file. 
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T INPUT ( ICOUNT , IBUPPR , IPRMPT ) 


ICOUNT  Is  the  number  of  ASCII  characters  to  be  accepted 
from  the  terminal. 

IBUPPR  Is  a buffer  Into  which  the  ASCII  characters  will 

be  placed  one  character  per  word,  right-justified, 
zero-fill.  The  buffer  is  considered  to  contain 
ICOUNT  words, i 

IPRMPT  Is  an  array  containing  a prompt  sequence  which 
Is  used  to  Initiate  the  Input  operation.  The 
first  word  of  the  array  contains  a count  of  the 
number  of  characters  In  the  prompt  sequence  and 
Is  also  the  number  of  words  in  the  IPRMPT  array 
minus  1 . The  prompt  characters  are  In  the  same 
format  as' would  be  passed  to  TOUTPT. 

Comments;  This  routine  Initiates  an  Input  operation  which 
asks  for  ICOUNT  ASCII  characters  to  be  read  from 
the  terminal.  If  less  than  ICOUNT  characters 
are  received,  the  remaining  buffer  positions  are 
zero-filled.  If  more  than  ICOUNT  characters  are 
received,  excess  characters  are  Ignored.  The 
input  operation  Is  prefixed  by  sending  the  prompt 
sequence  to  the  terminal  (If  IPRMPT(I)  Is  not 
equal  to  zero).  Preferably,  this  would  occur  as 
part  of  the  Input  request  but,  on  some  systems. 

It  may  be  necessary  to  call  TOUTPT  to  send  the 
prompt  to  the  terminal.  The  Important  thing  Is 
to  make  the  delay  between  the  time  the  prompt 
la  apparent  to  the  terminal  operator  and  when 
Input  can  be  accepted  by  the  operating  system 
Indetectable  to  the  terminal  operator. 

Note  that  Input  characters  placed  in  IBUPPR  must 
be  ASCII.  If  ASCII  originates  at  the  terminal, 
the  characters  must  not  be  modified  before  being 
placed  In  the  buffer.  It  Is  also  Important  that 
any  characters  being  buffered  within  TOUTPT  or 
the  operating  system  be  sent  to  the  terminal 
prior  to  the  prompt  sequence. 


j 

26 


( 


TOUTPT ( ICOUNT , I3UPPR ) 


ICOUNT  Is  the  number  of  characters  to  be  transmitted 
to  the  terminal. 

I3UPPR  Is  an  arra7  of  ICOUNT  words.  Each  word  contains 
one  ASCII  character,  right-justified , zero-fill. 

Comments:  This  routine  transmits  the  ASCII  characters 

within  IBUPPR  to  the  terminal  unmodified  with 
no  additional  characters  Inserted..  If  desirable, 
the  characters  ma7  be  packed  into  buffers  before 
sending  to  the  terminal.  In  this  case,  the 
buffer  should  be  sent  when  full  or  when  TOUTPT 
Is  called  with  ICOUNT  equal  to  zero. 


IV.  3D  GCS  Implementation  Pactora. 

3D  GCS  malces  few  assumptlona  about  the  capabilities  of 
the  computer  and  operating  system  in  whose  environments  it 
will  function.  Essentially,  3D  GCS  (or  even  2D  GCS)  can 
be  successfully  and  easily  supported  on  any  computer  system 
which  has  the  following  characteristics: 

a)  A word  size  of  32  bits  or  larger. 

b)  A loader  which  allows  several  libraries  to  be  searched 
during  the  linkage  edit  of  the  user  program. 

c)  A capability  for  reading  and  writing  direct  access 
(random  access ) files. 

d ) A capability  for  sending  arbitrary  length  strings  of 
ASCII  characters  to  a display  device  (required  for 
interactive  devices  only). 

With  these  capabilities,  it  is  a relatively  straight-forward 
task  to  bring  up  3D  GCS.  Section  7 contains  a phased  sequence 
for  accomplishing  this. 

Circumventing  the  lack  of  any  of  these  capabilities  or 
characteristics  can  be  a laborious  undertaking  and,  in  the 
case  of  direct  file  I/O,  may  not  even  be  possible.  The 
following  paragraphs  are  designed  to  assist  the  implementor 
in  modifying  3D  GCS  to  accommodate  limitations  in  the  host- 
computer  system. 

Word  Size 


GCS  was  originally  developed  for  computers  whose  words 
consist  of  at  least  32  bits  and  in  which  may  be  stored  at 
least  four  host-computer  characters.  There  are  only  three 
areas  in  3D  GCS  where  this  limitation  is  critical. 

Wherever  GCS  mode  and  option  names  are  specified,  only 
the  first  four  characters  of  each  mode  or  option  name  are 
significant.  3D  GCS  assumes  these  four  characters  occupy 
positions  in  the  same  word.  The  processing  of  these  modes 
and  options  takes  place  in  many  GCS  routines.  Besides 
USST  and  U?SBT,  included  in  these  routines  are  UCOLOR, 
UDOIT,  C?0RKT,  CQUERY,  all  user-callable  segmentation 
routines,  and  all  user-callable  structure  routines.  These 
routines  all  call  the  computer-dependent  routine  GCSSTD  to 
extract  the  first  four  characters  of  the  option.  GCSSTD 
can  be  written  to  process  multiple-word  character  strings. 
However,  the  comparisons  which  take  place  in  U3ET,  UPSET, 
UQUERf,  and  the  others  will  require  code  modification  to 
cause  correct  matching.  An  easier  solution,  if  available, 
is  to  use  double  word  integers. 
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There  are  several  areas  within  GC3  In  which  character 
string  constants  are  define  and  Initialized  by  DATA 
statements  (e.  g.,  UTAXIS).  These  will  have  to  be  located 
and  modified  as  necessary.  They  can  frequently  be  found  by 
looking  for  the  character  strings  "/AH’*  and 

The  third  area  In  which  GCS  requires  this  restriction 
la  In  the  storage  of  character  descriptors  for  the  GCS 
character  set.  Bach  stroke  of  a character  la  stored  In  a 
2A-blt  field  In  the  lower  portion  of  a computer  word  as 
follows: 


f 


This  24-blt  field  Is  split  Into  the  three  8-blt  subfields 
shown  above.  The  X and  Y bytes  represent  percentages  of  a 
character  enclosing  box  In  sign/ magnitude  format. (3=1 
represents  negative).  The  MMM  field  has  value  0 for  a 
visible  stroke  and  has  value  5 for  a move.  The  T field 
flags  the  last  stroke  In  the  character  when  set  to  1 . 

While  It  Is  possible  to  store  the  character  stroke  In  a 
three-byte  field,  unless  a computer  Is  byte-addressable, 
such  a packing  scheme  Is  too  Inefficient  to  be  acceptable. 
Once  again,  use  of  double-word  Integers  Is  Indicated,  If 
available.  If  not,  each  stroke  may  be  stored  In  two-word 
table  entries  with  the  appropriate  changes  made  to  the 
referencing  code  In  GCSSIM  and  GCSSYM.  The  recommended 
split  la  to  place  the  opcode  (MMM),  termination  (T),  and 
Z fields  In  one  word  and  the  Y field  In  another.  The 
termination  field  should  be  moved  down  so  that  It  does  not 
make  the  contents  of  the  word  negative  when  referenced 
arithmetically. 


Ovcllc  Library  Searches 


GCS  la  organized  Into  device-independent  routines, 
computer-dependent  routines  (which  are  device-independent), 
and  device-dependent  routines.  Normally,  all  device- 
independent  routines  are  stored  In  one  device-independent 
library,  and  each  set  of  device-dependent  routines  are 
stored  In  a separate  device-dependent  library.  The 
appropriate  device-dependent  library  Is  selected  at  load 
time  for  the  device  to  be  used.  A linkage  editor  or  loader 
which  can  search  several  libraries  as  If  one  (actually, 
logically  concatenate  the  libraries)  Is  a great  aid  In 
using  GCS  on  a computer  system.  Such  an  editor  will  perform 
a cyclic  search  to  satisfy  all  external  references.  Some 
linkage  editors  and  loaders  cannot  search  a library  a second 
time.  Frequently,  this  effect  can  be  achieved  by  listing 
the  device-independent  and  device-dependent  libraries  twice 
causing  each  to  be  searched  twice.  A more  practical  approach 
might  be  to  store  the  computer-dependent  routines  and  GC3SIM 
in  each  of  the  device-dependent  libraries. 
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f Direct  Access  I/O 

It  will  be  very  difficult  to  support  GCS  on  a computer 
system  which  does  not  support  direct  access  file  I/O.  This 
is  because  both  the  GCS  structure  capability  and  the  GCS 
I segmentation  capability  require  direct  access  files  for 

storing  the  data.  (It  is  also  intended  that  the  planned 
support  for  Hershey  characters  will  require  that  these  also 
be  stored  on  a direct  file).  The  best  attempt  to  support 
GCS  on  such  a computer  system  would  be  to  simulate  direct 
access  files  using  sequential  files.  It  should  not  be 
expected  that  GCS  will  function  efficiently  when  using 
structures  or  segmentation  in  this  case. 

Telecommunications  Protocol 

>fhen  sending  graphics  commands  to  a display  device 
connected  via  a telecommunications  line,  GCS  assumes  that 
any  number  of  characters  can  be  transmitted  to  the  display 
device  without  sending  some  system-dependent  end-of-line 
terminator  character  such  as  a carriage  return  character. 

At  times,  such  lines  may  exceed  the  capacity  of  an  operating 
system  buffer.  This  is  not  critical  provided  the  operating 
system  does  not  insert  such  an  end-of-file  character  arbi- 
trarily within  the  logical  stream  of  data.  If  it  does,  the 
correctness  of  the  picture  being  displayed  may  be  thwarted. 
Svery  attempt  should  be  made  to  provide  such  a transparent 
flow  of  characters  to  the  terminal.  If  it  cannot  be  accom- 
plished, the  device-dependent  routines  within  GCS  must  be 
modified  to  bracket  the  inserted  end-of-line  characters  with 
commands  that  keep  the  end-of-line  characters  from  effecting 
the  visual  output.  Note:  input  operations  do  not  require 
an  unlimited  line  length. 


Phased  Implementation  Sequence. 

The  following  steps  describe  the  sequence  of  actions 
necessary  to  bring  3D  GCS  up  on  a new  coaiputer  system.  It 
is  assumed  that  3D  GCS  source  is  available  on  tape  in  the 
form  of  card  images. 

1 ) Read  the  source  tape  on  to  disk  in  a form  in  which  the 
source  can  be  manipulated  using  the  host-computer 
standard  soiurce  program  library  maintenance  procedures. 
Note  that  for  proper  organization  later  into  object 
libraries,  it  may  be  necessary  to  store  the  device- 
independent  source  programs  in  one  file  and  each  set  of 
device-dependent  source  programs  in  separate  files. 

Other  computer  systems  may  allow  all  the  source  programs 
to  be  kept  together.  If  an  INCLUDS,  COPY,  or  *CALL 
capability  is  available,  the  Graphics  Status  Area  (GSA) 
should  be  placed  in  a nodule  which  can  be  Included  and 
the  code  in  the  source  programs  reolaced  with  COPY'S, 
INCLDDB's,  etc. 

2)  Establish  the  computer-dependent  Initializations  for  the 
Graphics  Status  Area.  Then  edit  these  values  into  the 
appropriate  places  in  the  source  code  where  the  GSA 
initialization  statements  are  located. 

3)  Implement  the  computer-dependent  routines  described  in 
this  document.  These  should  be  thoroughly  tested  before 
attempting  to  use  them  within  GCS.  Once  debugged,  the 
source  code  should  be  placed  with  the  other  device- 
independent  source  programs. 

4)  Compile  all  device-independent  routines  into  one  object 
library  in  a form  which  can  be  searched  by  the  loader  or 
linkage  editor.  If  compilation  errors  are  detected, 
they  should  be  corrected  and  this  step  repeated  until  no 
compilation  errors  occur. 

5)  Compile  all  device-dependent  routines  for ''the  devioe 
upon  which  development  will  occur  into  another  object 
library  in  a form  which  can  be  searched  by  the  loader 
or  linkage  editor.  If  compilation  errors  are  detected, 
they  should  be  corrected  and  this  step  repeated  until 
no  compilation  errors  occur.  It  is  highly  recommended 
that  the  development  device  selected  be  one  for  which  a 
set  of  GCS  device-dependent  routines  already  exists 

even  if  this  must  be  an  alphanumeric  device  (alphanumeric 
terminal  or  line  printer). 


( 


6}  Write  a test  program  which  Invokes  the  basic  GCS  functions. 

A typical  such  program  might  be  as  follows: 

CALL  USTART 

CALL  USBT{"P£RCEilT  UNITS") 

CALL  UDAR£A(0.,100.,0.,100. ) 

CALL  UM075(0. ,0.  ) 

CALL  UP£N(100. ,100. ) 

CALL  UPRINr(50.,50. ,"TBXT  ") 

CALL  USNL 

STOP 

SNU 

This  program  will  draw  a diagonal  line  from  the  lower 

left  corner  of  the  display  surface  to  the  upper  right 

corner  of  the  display  surface  and  will  display  the 

word  "TEXT"  at  a location  vrtiere  the  lower  left  corner 

of  the  first  character  position  Is  at  the  center  of  the 

display  surface  with  the  characters  extending  to  the 

right.  Continue  testing  CCS  until  It  Is  apparent  that 

CCS  Is  functioning  satisfactorily  for  the  development 

device.  Note  that  to  use  CCS,  It  will  be  necessary  to 

Insure  that  the  BLOCK  DATA  subroutine  for  the  display  : 

device  selected  be  loaded  since  It  Is  the  subroutine 

which  Initializes  the  CSA.  { 

7)  Repeat  steps  5 A 6 for  each  display  device  to  be  supported. 

Read  the  GrCS  Device-Dependent  Implementation  Guidelines  ; 

If  a device  not  already  supported  by  CCS  Is  to  be  used. 

8)  Design  and  Implement  a control  card  procedure  or  other  | 

mechanism  which  makes  device  selection  convenient  for 

the  user.  Typically,  this  can  be  accomplished  by  passing 

the  name  of  the  device  to  the  control  card  procedure  as 

a parameter.  The  control  card  procedure  will  then  cause 

the  appropriate  control  cards  to  be  processed  so  that  | 

the  appropriate  device-dependent  library  will  be  used  by 

the  linkage  editor  or  loader.  While  this  step  Is  optional,  , 

It  Is  strongly  recommended  since  It  greatly  facilitates 

using  CCS. 
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VI.  InstructloiTJ  for  Installing  GCS  Charqcter  Fonts . 

There  are  four  components  required  for  Installing  GCS 
character  fonts.  Each  component  should  be  placed  In  a 
separate  file  as  described  below. 

1 ) Character  Location  Record s--These  are  card  images 
of  the  form; 

DATA  LCXXXX(fY)/RRDDDD/ 

where;  XXxX  is  the  font  name. 

YY  Is  the  font  character  ASCII  index-31 . 
RRDDDD  Is  the  record  number  and  record 
displacement  of  the  start  of  the 
character  descriptor. 

These  record  should  be  placed  In  Fortren  file  number  1 . 

2)  Character  Width  Records — These  are  card  images  of  the 
form: 

DATA  LWXXXX(YY)/ZZZZ/ 

where:  XXXX  Is  the  font  name. 

YY  Is  the  font  character  ASCII  lndex-31 • 

ZZ2Z  Is  the  character  i;ldth  percentage  for 
proportional  spacing. 

These  records  should  be  placed  In  Fortran  file  number  2. 

3)  Character  Descriptor  Records — These  are  card  Images  of 
the  form: 

DATA  ICXXXX(YYYY)/  ZZZZZZZ/ 

where:  XXXX  Is  the  font  name. 

YYYY  Is  the  stroke  displacement  from  the 
beginning  of  the  font. 

ZZZZZZZ  Is  the  font  character  stroke  descriptor. 
These  records  should  be  placed  In  Fortran  file  number  3» 

4)  Font  File  Construction  Program--Thls  Is  a GCS  Fortran 
program  which,  when  compiled  and  executed,  reads  data 
fro.'Q  Fortran  files  1 , 2,  and  3 and  creates  the  direct 
access  font  flic  using  the  GCS  computer-dependent 
random  file  routines.  The  first  statement  of  this 
program  Is  a PROGRAM  statement  required  by  some 
comj^ter  systems  for  main  programs.  If  this  statement 
l3!!ircqulred , It  may  be  deleted.  The  program  places 
the  output  on  Fortran  file  11.  This  is  a random  file 
which  should  be  saved  as  a read-only  file  In  the 
computer  system  library.  Users  of  the  GCS  character 
font  facility  will  need  to  access  this  file  using  a 
Fortran  file  number  they  specify  with  the  UPSET 
(«FNTPILE'',fllenr ) command. 
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In  accordance  with  letter  from  DAEN-RDC,  DAEN-ASI  dated 
22  July  1977,  Subject:  Facsimile  Catalog  Cards  for 
Laboratory  Technical  Publications,  a facsimile  catalog 
card  in  Library  of  Congress  MARC  format  is  reproduced 
below. 


Puk,  Richard  F 

Host -computer  implementation  guidelines  for  the  three-dimen- 
sional Graphics  Compatibility  System  (CCS)  / by  Richard  F.  Puk, 
Albuquerque,  N.  Mex.  Vicksburg,  Miss.  : U.  S.  Waterways  Ex- 
periment Station  ; Springfield,  Va.  ; available  from  National 
Technical  Information  Service,  1979. 

53  p.  ; 27  cm.  fMiscel laneous  paper  - U.  S.  Army  Engineer 
Waterways  Experiment  Station  ; 0-79-1) 

Prepared  for  Office,  Chief  of  Engineers,  U.  S.  Army,  Wash- 
ington, D.  C. , under  Contract  No.  DACA39-78-M-00S3. 

1.  Computer  graphics.  2.  Computer  systems  programs.  3.  Graphics 
Compatibility  .System.  4.  Guidelines.  I.  United  States.  Army. 
Corps  of  Engineers.  11.  Series:  United  States.  Waterways  Ex- 
periment Station,  Vicksburg,  Miss.  Miscellaneous  paper  ; 0-79-1. 
TA7.W.34m  no.  0-79-1 
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